The following is a list of the known problems in this release of ODF. This includes the Radar Bug Tracking number, the bug title, details of the problem, and, in some cases, a workaround.
1291628
Screen not updated behind print dialogs
When using QuickDraw GX printing...
— Open ODFDraw by double clicking its stationery
— Choose "Page Setup..." from the Document menu to show the page setup dialog
— Move the dialog box
The screen area under the movable dialog box doesn't get updated. This goes for both the part of the screen covered by the ODFDraw document window and the parts of the screen that are covered by the windows of other applications.
The print job dialog has the same problem.
1269330
ODFDraw does not call ODFacet::DrawnIn() when embedded in offscreen canvas
When ODFDraw draws asynchonously (in responce to MouseDown) it does not call ODFacet::DrawnIn(). This means the result of mouse down actions do not show up when the part is embedded in an offscreen canvas.
I did not check other example parts, but they may not work either.
To be more specific: Shapes are drawn, but shape handles (resulting from selection changes) are not.
1307571
FW_CPolys needs more functionality
1) FW_CPolys have no "InsertPoint"/"RemovePoints" methods: working with static polys is useless.
Unfortunately, it is not easy to add this with some subclassing: fields like fCount are private and there is no Setter method (in FW_CPolygonRep).
1322787
Scrolling Focus
ODF Release 1 doesn't support the scrolling focus API.
1328076
Button should activate itself if it's at the root?
When opened at the root, there is no "About ODFButton". Maybe a button should activate itself if it's at the root.
1330884
ChangeKind not Implemented
ODF Release 1 doesn't support the ChangeKind API.
1331222
No FW_CBitmap::GetColor(x,y)
To obtain a color of the bitmap at the particular point you need the FW_CBitmap::GetColor(x,y) API.
1331797
Arrow keys in FW_CEditView not HI compliant
There are the following problems with how arrow key selection works right now:
• If you select a block of text, then press the left or the right arrow key, the cursor should move to the beginning (end) of the original selection. Right now, it moves one character away from the original selection.
• If you hold down the shift key and press the left or right arrow key, the selection should be extended in that direction. Right now, shift-arrow works just like arrow.
1332622
Crash when getting window position
I wanted to get the position of a floating window before it was deleted, so I called GetWindowPosition right before deleting it in ReleaseAll. This caused a crash in FW_GetWindowBorderSize. I haven't tracked this any further, as I probably won't be doing this in this manner eventually, but it seems that the FW_CWindow object can get into an ambiguous state before it is deleted that causes a call like this into it to crash.
1330586
FW_CEditView doesn't use its fMaxChars field
The maximum number of chars entered in an edit-view can be passed to the ctor, but is ignored for now.
1334227
Apple menu is enabled when dialog is shown
When a modal dialog is shown by ODF (including one that isn't movable), the Apple menu is still enabled. You can still show the about box.
If you choose, say, a control panel from the Apple menu, the program will beep. Then, when you close the dialog, the Finder will launch the control panel.
Comment:
You're right about non-moveable modal dialogs, the Apple menu should be disabled (For moveable modal dialogs the OpenDoc Programmer's Guide says on page 246 that the Apple menu should stay enabled).
I changed FW_CMenuBar::MacEnableMenuBar to include the Apple menu and added an argument in FW_CPart::PrivEnabledMenuBar() to enabled the Apple menu for moveable dialogs
1341357
Scroll bars are drawn during activate event even if they are invisible
FW_CScrollBar::DoActivateEvent doesn't check the Visible flag of scroll bars before drawing them during window activate events.
Work-around: subclass FW_CScrollBar and modify DoActivateEvent, or patch the framework directly.
1329673
ListBox scrollbar bug: Mouse location may be off a few pixels when clicking in.
When clicking in a list box scrollbar the mouse location may be offset by a few pixels. (should not be more than 8 pixels) Sometimes this causes the scrollbar to not respond to the click because the mouse is handled as being outside the scrollbar rectangle.
1329679
Labels of grayed out buttons don't print
Labels of grayed out buttons don't print (because we use pictures to print Mac controls).
1332644
FW_CListBox scrollbar doesn't print
Basic printing of a list box works except for the scrollbar.
1336104
Controls don't work well in multiple facets
Embed ODFForm in ODFEmbed and explode in 4 facets... everything is not working quite right because native controls are difficult to handle in multiple facets.
1340299
Deleting the target view doesn't reset the frame's target
When you delete a view, the framework doesn't check whether that view is the input target. So if you have, for example, an active edit view, and you delete it, there will still be a dangling reference to the view you deleted. Next time you try to make a menu selection, you will crash.
The work-around is to add this in the class destructor of View objects that are deleted explicitely by the user:
~CMyView()
{
if (this == GetFrame(ev)->GetTarget(ev))
ResignTarget(ev);
}
1326238
Controls always have white background color.
The background color of controls is always white. When displaying controls in a colored area, you need controls whose background color conforms to the surrounding area.
The work-around is to define a color table for the frame's window in the FacetAdded() method (see CPwdDialogFrame::FacetAdded() in the Form example), it will be used by the controls too.
Or else define a color table for individual controls.
1334156
FW_CEditView doesn't support Undo
The edit menu items Select All and Undo are not supported by FW_CEditView.
SelectAll works, Our test part was disabling the command.
Undo is not supported for now in FW_CEditView.
1340419
No notification for list box selection
Currently, FW_CListbox will send a notification when an item is double clicked but no notification when an item is selected.
Sometimes you need to be notified when an item gets selected. You may for example want a change in the listbox selection to change the state of another control. In a typical font dialog, there is a list box with built-in fontsizes an a text edit view that lets you type in any font size. When a font size is selected in the list, the text edit field changes accordingly.
The Mac List manager doesn't tell us when a cell is being selected. ::LClick handles the mouse click internally and returns true only when a double-click occurs.
One work-around to detect selection on a mouse down is to implement a mouse behavior like the one done in FormView.cpp in the Form sample
1341815
Need API to change Scroller's scroll units
In ODF 1 the only way to change a scroller's scroll unit (minor and major) is to override GetScrollUnits in a subclass of FW_CScroller. Scroll units are hard coded as follows:
minor = 1/10 of the visible content size in the same direction
major = the visible content size in the same direction.
Additional comment:
I think the scroller should ask the content view what the scroll units are. I know this is not easy because of indirect connection, but from an ODF user point of view, it makes sense because the content view knows its layout. The scroller does not have to.
1342164
FW_CListBox always uses white color to erase the target border
When a list box resigns the target, it uses white color to erase the target border. This is not what you want if the background is not white.
1330858
Crash during FW_CBitmap creation
If you create a bitmap context ( on stack ) and after (the next line - before it is destructed ) try to create a bitmap from the FW_PPicture - system crashes.
This is a problem in FW_CGraphicContext which uses SetPort instead of SetGWorld.
1326552
Zoomed ODFDraw border not respected by ODFClock
Embed ODFClock (analog) in ODFDraw. Zoom ODFDraw to 200%. Position clock so it extends beyond the right edge of the drawing area. As the second hand sweeps by it will intrude into the vertical scroll bar slightly.
Less reproducible but I'd swear I've seen it: intrusion into the horizontal scroll bar; and a 1-pixel whitespace gap between the second hand and the rulers at top or left.
It might be an OpenDoc Imaging bug but the only tool we have to reproduce it right now is ODFDraw, so we’re starting by assigning it to that component.
1344763
68K ODF parts crash on a system with QuickDraw GX installed.
